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ABSTRACT 


A single cryptographically enhanced product is capable of 
exposing various strengths of cryptography. When first 
installed, the product exposes only a low-level, exportable 
strength cryptography that may be used in both the U.S. or 
overseas with a general export license. Stronger cryptogra- 
phy is implemented in the product, but is not exposed to the 
user. To enable the stronger cryptography, the user must 
obtain an authorization certificate issued from a certifying 
authority. The authorization certificate contains an identity 
of the certifying authority and a token granted by the 
product's provider. The token contains capabilities to expose 
the stronger cryptography in the product and an encoded ID 
of the certifying authority, which binds the token to a 
specific certifying authority. The cryptographic product 
evaluates the authorization certificate and token to verify 
that the certificate is from the certifying authority, the token 
is from the product provider, and the token contains the hash 
digest of the certifying authority. The product also deter- 
mines whether the certificate or token has been revoked or 
has expired. If everything checks out, the product uses the 
capabilities included in the token to expose the higher 
strength cryptography to the user; otherwise, the product 
denies the request for higher strength cryptography and 
continues to use only the low strength cryptography. 

40 Claims, 7 Drawing Sheets 
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SYSTEM AND METHOD FOR ENABLING 
DIFFERENT GRADES OF CRYPTOGRAPHY 
STRENGTH IN A PRODUCT 

TECHNICAL FIELD 

This invention relates to products that employ crypto- 
graphic functionality. More particularly, this invention 
relates to an architecture that enables a user of such products 
to enable various grades of cryptography strength in those 
products. 

BACKGROUND 

Cryptographic ciphers are often measured and described 
in terms of their strength. Different ciphers offer different 
strength depending on how hard they are to break. "Strong" 
ciphers are more difficult to break than "weak" ciphers. 
Different types of data lend themselves to different strengths 
of cryptography. For instance, if the cost required to break 
a cipher is greater than the value of the protected data, that 
particular cipher is most likely appropriate for the data even 
though the cipher may be relatively weak compared to other 
ciphers. If the time required to break a cipher is longer than 
the time needed to keep the protected data secret, the cipher 
is properly suited for the data. 

In public key cryptography, the cipher typically derives its 
strength from the length of the key used to encode the data. 
A "key" is a string of bits and its "length" is expressed in the 
number of bits in the string. The same cipher can be weak 
or strong depending upon the key length. A cipher with a 
comparatively short key length (e.g., 40 or 56 bits) may be 
considered weak, whereas the same cipher with a compara- 
tively long key length (e.g., 128 bits) may be deemed strong. 
It is common today for various software products to employ 
ciphers with 40-bit or 56-bit keys, which are generally 
characterized as weak, as well as ciphers that employ 128-bit 
keys, which are generally considered to be strong. 

Because of their potential for illegal or improper use, 
cryptographic ciphers cannot be exported from the United 
States without approval from the U.S. government. 
Generally, products with "weak" ciphers having short key 
length may be exported. Such products are said to have 
"exportable strength" cryptographic functionality. Products 
with "strong" ciphers having long key lengths are usually 
not permitted to leave the country. To export a cryptographic 
product from the U.S., the product manufacturer or exporter 
must first obtain an export license from the U.S. govern- 
ment. 

As a result of this government policy, the makers of 
cryptographically enhanced products face a dilemma. They 
would like to make a single product that can be sold in the 
U.S. and exported abroad without the hassle of securing 
special export licenses for each and every foreign market. 

FIG. 1 illustrates this point. A cryptographic product 
provider 10 makes a single product 12 that utilizes crypto- 
graphic services, such as encryption, decryption, digital 
signing, and authentication. To enable global exportation to 
Europe and Asia without having to secure special export 
licenses, the provider 10 typically configures the product 
with a weak "exportable-strength" cipher. As a result, the 
U.S. version of the product is likewise pared down to the 
lowest exportable-strength cipher. However, some U.S. cus- 
tomers might request and be entitled to use higher strength 
ciphers. Such customers must submit special requests to the 
provider, along with proof of residence and proposed use, 
before the provider 10 can release a stronger version of the 
product. 


Accordingly, there is a need to provide an improved 
technique for supplying cryptographically enhanced prod- 
ucts throughout the world. 

5 SUMMARY 

This invention concerns an architecture that selectively 
exposes various grades of cryptographic strength in the same 
product. A product provider manufactures one cryptographi- 
cally enhanced product that can be marketed to users in the 

30 U.S. and exported to users abroad. Once installed, the 
product initially exposes only a low-level, exportable- 
strength cryptography that may be used in both the U.S. or 
overseas with a general export license. Stronger cryptogra- 
phy is implemented in the product, but is not exposed to the 

35 user. It is also not required to expose by default all algo- 
rithms supported by the cryptographic product. It is possible 
to use this same mechanism to only expose the existence of 
an algorithm when authorized to do so. 

2Q To enable the stronger cryptography with the product, the 
user must first obtain a certificate that contains the capabili- 
ties to expose the stronger cryptography in the product. The 
certificate is issued to the user from a certifying authority. 
The certifying authority, in turn, obtains the enabling capa- 

25 bilities from the product provider. The process of requesting 
and receiving the certificate enables the product provider to 
ensure that the certifying authority, and ultimately the user, 
is legally able to employ the stronger cryptography in the 
product. 

3 0 According to one implementation, the certifying authority 
submits a request to the product provider for higher strength 
cryptography. The request contains an identity certificate 
that uniquely identifies the certifying authority. The product 
provider authenticates the identity certificate and verifies 

35 whether the certifying authority can use higher strength 
cryptography. The product provider may evaluate such 
policy considerations as where the certifying authority 
resides, to whom the certifying authority intends to issue 
certificate, and the purpose for which the enhanced strength 

40 product is to be used. If the policy considerations are met, 
the product provider creates a token that contains the capa- 
bilities to enable the higher strength cryptography within the 
product. The token should have a means of verifying the 
integrity of the token such as a digital signature to ensure 

45 that any attempt to alter the token can be detected. The token 
also contains a hash digest of the identity certificate, thereby 
binding the certifying authority to the enabling token. 

When the user desires higher strength cryptography, the 
user submits a request to the certifying authority for the 

50 higher strength cryptography. The request contains the 
user's public key. The certifying authority authenticates the 
user and determines whether the user can use the higher 
strength cryptography. The certifying authority may have its 
own set of policy considerations such as where the user is 

55 located, the purpose for using the higher strength 
cryptography, and so on. If the policy parameters are 
satisfied, the certifying authority creates a certificate that 
contains the certifying authority identity and the signed 
token issued by the product provider. The certifying author- 

60 ity returns the certificate with the signed token to the user, 
where it is stored locally on the user's computer. 

When the user desires the extra strength cryptography 
from the product, the certificate containing the signed token 
is passed into the product. The cryptographic product evahi- 

65 ates the certificate and signed token in several ways. First, 
the product verifies that the certificate is truly from the 
certifying authority. Second, the product verifies that the 
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signed token is truly from the product provider. Third, the The cryptographic -based product may alternatively be 

product ensures that the signed token contains the hash implemented as a service layer. For instance, the product 

digest of the certifying authority, thereby linking the certi- might comprise a set of one or more DLLs (dynamic link 

fying authority with the product provider. Fourth, the prod- libraries) that provide cryptographic services to application 

uct determines whether the certificate or signed token has 5 programs via a set of APIs (application program interfaces), 

expired. Fifth, the product determines whether the certificate One specific example of a service layer product is the 

or token has been revoked. cryptographic service providers (CSPs) developed by 

If all verification steps return true, the product uses the Microsoft Corporation. The CSPs perform cryptography 

capabilities included in the signed token to expose the higher functions and manage cryptographic keys used in the func- 

strength cryptography to the user. On the other hand, if any ™ tions. For instance, one or more CSPs are configured to 

step returns false, the product denies the request for higher perform encryption, decryption, digital signing, and verifi- 

strength cryptography and continues to use only the low cation functions using certain types of cryptographic algo- 

strength cryptography. rithms and keys. The CSPs are implemented as dynamic 

linked libraries (DLLs) that are loaded on demand by a 

BRIEF DESCRIPTION OF THE DRAWINGS 15 cryptographic application program interface (CAPI) and 

FIG. 1 is a diagrammatic illustration of a conventional called by the application through the CAPL The CSP and 

distribution setting in which a cryptographic product pro- CAPI architecture is described in more detail in U.S. Pat. 

vider distributes a cryptographically enhanced product No. 5,689,565, entitled "Cryptography System and Method 

throughout the world. for Providing Cryptographic Services for a Computer 

FIG. 2 is a diagrammatic illustration of a system for 20 Application", which issued Nov. 18, 1997, and is assigned to 

enabling different grades of cryptography strength in a Microsoft Corporation. This patent is incorporated by ref- 

product. erence. 

FIG. 3 is a block diagram of a computer that can be used It is further noted that the cryptographic-based product 

to implement various participants in the system. ca & be implemented in forms other than software programs 

FIG. 4 is a flow diagram showing steps in a method for 25 and modules. Alternative product implementations include 

supplying a product that is capable of having varying grades firmware embedded in memory, or a hardware component 

of cryptographic strength ( e -8-» modem), or some other tool that utilizes cryptographic 

FIG. 5 is a flow diagram showing steps in a method for ci P hers or of ^ ^ 

registering for capabilities to expose stronger cryptography 30 The svstem 20 distributes and enables the cryptographic 

in the product. strength according to a four-phase process. At phase I, the 

FIG. 6 is a flow diagram showing steps in a method for cryptographic product provider 22 supplies the 

issuing a certificate to a user to expose the stronger cryp- cryptographic-based product 28 to one or more clients 26. 

tography ^or purposes of continuing discussion, the product is a 

HO. 7 is a flow diagram showing steps in a method for 35 ^graphically enhanced software program as repre- 

utilizing the stronger cryptography. xm f ^ «»P»ter ^ ?*• In «bis example, the software 

t, c rot* Utl , product 28 is loaded on the client computer as a crypto- 

The same reference numerals are used throughout the r ,. . ~ n t . 4 . ,/ 

, . t c ,., c . , ~ graphic service layer 30 that is exposed to user applications 

drawings to reference like features and components. . , c r rr 
to ^32 via a set of APIs 34. 

DETAILED DESCRIFOON j n phase I, the product 28 is configured to expose a low 

The following discussion assumes that the reader is grade, exportable-strength cipher 36 having, for example, a 

familiar with cryptography. For a basic introduction of weak key length of 40 bits or 56 bits. One or more higher 

cryptography, the reader is directed to a text written by strength ciphers 38 (e.g., 128 -bit) are also implemented into 

Bruce Schneier and entitled "Applied Cryptography: the product, but are not exposed to the user at this point. 

Protocols, Algorithms, and Source Code in C," published by 45 When the user application 32 calls for a cryptographic 

John Wiley & Sons with copyright 1994 (or a second edition service 30 via the API 34, it is handed a handle to the weak 

with copyright 1996), which is hereby incorporated by cipher 36. The user application 32 is not permitted to access 

reference. the strong cipher 38. 

General Architecture To enable the strong cipher 38, the client 26 first obtains 

FIG. 2 shows a system 20 for providing a cryptographic- 50 a certificate to use higher strength cryptography in the 

based product that is capable of employing varying grades of cryptographic product. The certificate links an authorization 

cryptographic strength. The system 20 involves three pri- lo use higher strength cryptography with an identity of the 

mary participants: a cryptographic product provider 22, a particular certifying authority that is authorized to issue such 

certifying authority 24, and a user's client 26. The crypto- certificates to the user. Phases II to IV implement the 

graphic product provider 22 may be the manufacturer and/or 55 certification process. 

the distributor of the product. Alternatively, the product At phase II, the certifying authority 24 (or "CA") submits 
provider 22 might be a third party that is authorized to a request 40 to the cryptographic product provider 22 (or 
enable various grades of cryptographic strength in the prod- "CPP") seeking the capabilities to enable the higher strength 
uct - cipher 38. The certifying authority 24 might be a bank, or a 
The cryptographic-based product may be implemented in 60 company, or an association, or a specially dedicated entity 
a number of forms. The product may be implemented as a whose sole purpose is to grant certificates. The cryp to- 
computer application program that is stored at the client 26 graphic product provider 22 examines the request and veri- 
and executed on the client processor. Examples of fies that the certifying authority 24 is authentic and is able 
application-level products include online banking applica- to legitimately use the higher strength cipher. If the request 
lion programs, online trading application programs, elec- 65 is proper, the cryptographic product provider 22 supplies a 
Ironic commerce application programs, and email applica- digitally signed token 42 to the certifying authority 24 that 
tion programs. contains the enabling capabilities. The signed token 42 also 
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contains an encoded identity of the certifying authority 24, disk or hard disk array, a magnetic disk drive 66 for reading 

thereby binding the token to the specific certifying authority. from or writing to a removable magnetic disk 68, and an 

The token 42 can be traced to the cryptographic product optical disk drive 70 for reading from or writing to a 

provider 22. removable optical disk 72 such as a CD ROM or other 

At phase III, the client 26 submits a request 44 to the 5 optical media. The hard disk drive 64, magnetic disk drive 

certifying authority 24 seeking permission to enable the 66, and optical disk drive 70 are connected to the system bus 

higher strength cipher 38, The certifying authority 24 exam- 56 by a hard disk drive interface 74, a magnetic disk drive 

ines the request and verifies that the client 26 is authentic interface 76, and an optical drive interface 78, respectively, 

and is able to legitimately use the higher strength cipher. If Th e drives and their associated computer-readable media 

the request is proper, the certifying authority 24 issues a 10 provide nonvolatile storage of computer readable 

certificate 46 that contains the token 42, thereby binding instructions, data structures, program modules and other 

together the CA-issued certificate 46 with the CPP-issued data for the computer 50. 

token 42. The certificate 46 is signed by the certifying Although a hard disk, a removable magnetic disk 68, and 

authority and hence can be traced to the certifying authority. a removable optical disk 72 are described, other types of 

The client 26 stores the certificate with embedded token in 15 computer readable media can be used to store data. Other 

local memory. The certificate and token provide chains of such media include magnetic cassettes, flash memory cards, 

authority that enable the client to trace them back to their digital video disks, Bernoulli cartridges, random access 

issuers, the product provider 22 and certifying authority 24. memories (RAMs), read only memories (ROM), and the 

At phase IV, a user application 32 executing at the client l& e - 

26 calls via the API 34 to use the strong cipher 38. The 20 A number of program modules may be stored on the hard 

application 32 passes the certificate 46 with embedded token disk, magnetic disk 68, optical disk 72, ROM 58, or RAM 

42 to the cryptographic services 30. The service layer 30 60. These programs include a server operating system 80, 

examines the certificate 46 and verifies that it originated one or more application programs 82, other program mod- 

from the certifying authority 24 and has not been subse- ules 84, and program data 86. The operating system 80 is 

quently altered. The service layer 30 also examines the token 25 preferably a Windows-brand operating system such as Win- 

42 and verifies that it originated firom the cryptographic dows NT, Windows 95, Windows CE or other form of 

product provider 22 and has not been subsequently altered. Windows. The operating system 80 may alternatively be 

The service layer 30 further checks whether the token 42 other types, including UNIX-based operating systems, 

contains an encoded identity of the certifying authority 24. a user may enter commands and information into the 

When these checks return true, the service layer 30 enables 30 computer 50 through input devices such as a keyboard 88 

the strong cipher 38. On the other hand, if any one check and a mouse 90. Other input devices (not shown) may 

returns false, the service layer 30 denies the request for include a microphone, joystick, game pad, satellite dish, 

stronger cryptographic functionality. scanner, or the like. These and other input devices are 

A more detailed description of one implementation of the connected to the processing unit 52 through a serial port 

four-phase process is described below with reference to 35 interface 92 that is coupled to the system bus 56, but may 

FIGS. 4-7. Prior to describing this detailed method, alternatively be connected by other interfaces, such as a 

however, the following section describes a general-purpose parallel port, game port, or a universal serial bus (USB), 

computer that can be used to implement the participants in a monitor 94 or other type of display device is also 

the system 20. ^ connected to the system bus 56 via an interface, such as a 

Exemplary Computer Used to Implement Participants video adapter 96. The computer 50 has a network interface 

The cryptographic product provider 22 and certifying or adapter 98, a modem 100, or other means for establishing 

authority 24 are preferably implemented as computer communications over a network 102. 

servers, such as Windows NT servers that run the Windows It is noted that the system may be implemented using 

NT server operating system from Microsoft Corporation or 4S computing devices other than general purpose computers, 

UNIX-based servers. It is noted, however, that the crypto- such as a point-of-sale machine or kiosk that is employed by 

graphic product provider 22 and certifying authority 24 may merchants, or an automatic teller machine (ATM) used by 

be implemented using other technologies, including main- banks, or a computerized vending machine, or an electronic 

frame technologies. The client 26 can be implemented as ticket apparatus, or a set-top box. There are many different 

many different kinds of computers, including a desktop 50 forms that the computer 50 might assume, 

personal computer, a workstation, a laptop computer, a Phase I: Supply Product 

notebook computer, a handheld PC, and so forth. piG. 4 shows steps in a method for supplying a crypto- 

FIG. 3 shows an example implementation of a computer graphic product that is capable of employing varying grades 

50, which can be used to implement the cryptographic 0 f cryptography strength. This method is described with 

product provider 22, the certifying authority 24, and the 55 continuing reference to the system 20 shown in FIG. 1. 

client 26. The computer 50 includes a processing unit 52, a At step 120 in FIG. 4, the cryptographic product provider 

system memory 54, and a system bus 56 that interconnects 22 creates the cryptographic-based product with varying 

various system components, including the system memory grades 0 f cryptographic functionality. The product is con- 

54 to the processing unit 52. The system bus 56 may be figu re d lo expose exportable-strength cryptography func- 

implemented as any one of several bus structures and using 60 tionality. Higher strength cryptography is also implemented 

any of a variety of bus architectures, including a memory in the product, but securely hidden within the product. The 

bus or memory controller, a peripheral bus, and a local bus. higher strength cryptography can be exposed only through 

The system memory 54 includes read only memory capabilities granted by the cryptographic product provider 

(ROM) 58 and random access memory (RAM) 60. A basic 22. These capabilities might be implemented, for example, 

input/output system 62 (BIOS) is stored in ROM 58. 65 as a digital key used to unlock a signing algorithm to permit 

The computer 50 has one or more of the following drives: access to the higher strength cryptography. The first step 120 

a hard disk drive 64 for reading from and writing to a hard is optional (and hence illustrated as a dashed box) in that it 
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assumes the product provider 22 is also the manufacturer. Id 
situations where the product provider is not the 
manufacturer, step 120 may be omitted. 

At step 122, the cryptographic product provider 22 sup- 
plies the product 28 to the client 26. The product may be 
transferred a number of different ways. For instance, the 
product may be embodied on a physical memory disk that is 
sent through the mail or purchased by the user as a shrink- 
wrapped product from a retailer. Alternatively, the product 
provider 22 may download the product electronically over a 
network, such as the Internet, to the client 26. 

At step 124, the client 26 loads the cryptographic product 
into the computer for execution. Once loaded, the product 
initially exposes the export grade cryptography functionality 
(step 126 in FIG. 4). In our example, the product initially 15 
exposes the weak cipher 36, while keeping the strong cipher 
38 securely hidden. 

Because the product only exposes exportable grade 
strength, the product provider 22 can distribute the same 
product in the United States and abroad with a general 20 
export license from the U.S. government. The product 
provider 22 does not need to obtain a special export license 
because the higher strength cryptography cannot be exposed 
without the enabling capabilities supplied by the product 
provider. 

Phase II: Registration 

FIG, 5 shows steps in a method for registering with the 
cryptographic product provider 22 to receive capabilities for 
enabling higher strength cryptography. Most of the steps are 
implemented in software executing at servers resident at the 
cryptographic product provider 22 and the certifying author- 
ity 24. 

At step 130, the certifying authority 24 generates and 
sends a request 40 for stronger grade cryptographic func- 
tionality. The request 40 contains an identity certificate that 
uniquely identifies the certifying authority 24. The CA 
identity certificate includes the certifying authority's public 
key, a serial number, and other data pertaining to the identity 
and residence of the certifying authority. The request 40 
further includes the strength of cryptography being sought 
(e.g., 128 -bit). The request might also include any necessary 
export licenses or foreign government clearances that dem- 
onstrate the CA's authority to use the higher strength 
cryptography in the U.S. or abroad. 

The request may be transferred to the product provider 
electronically over a network, or hand-carried or mailed on 
a disk. If the request 40 is transferred over a public network 
(e.g., Internet), the certifying authority may further encrypt 
the request using a public key encryption algorithm, such as 
RSA. 

The cryptographic product provider 22 receives the 
request (step 132 in FIG. 5) and authenticates the certifying 
authority using the certificate contained in the request 40 
(step 134). The product provider verifies that the certifying 
authority is a legitimate entity, that it exists at the location 
it stipulates, that it has a legitimate purpose for using the 
high strength cryptography, and so forth. As part of this 
process, the product provider also verifies that the certifying 
authority resides within the United States or has an export 
license in a country that permits use of extra strength 
cryptography, and hence is legally capable of utilizing the 
stronger cryptography (step 136). 

At step 138, the product provider 22 computes a hash 
digest of the CA identity certificate using a one-way hashing 
function H, as follows: 

Hash Digest=//(CA identity certificate). 


35 


50 


55 


60 
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At step 140, the cryptographic product provider 22 creates 
a signed token 42 that contains the hash digest of the CA 
identity certificate. The token can be implemented as a 
certificate, such as an X.509 certificate. Table 1 shows the 
structure of the signed token 42 when implemented as an 
X.509 certificate. 

TABLE 1 

Token Structure 


Field 


Function 


Version 
Serial Number 
Algorithm ID 

Issuer 

Period of Validity 
Subject 

Subject's Public Key 


Signature 
Extension 


Identifies the certificate format. 
Unique identifier assigned to certificate. 
Identifies the type of algorithm used to sign the 
certificate, together with any parameters. 
Name of the cryptographic product provider. 
Specifies a pair of dates, between which the 
certificate is valid. 
Name of the certifying authority. 
Specifies a cryptography algorithm, 
parameters used in the algorithm, and the 
subject's public key (i.e., the certifying 
authority's public key). 
Signature of issuer, which in this case is the 
cryptographic product provider. 
Holds additional data and information that an 
issuer may wish to include, or a subject may 
wish to have included, as part of the certificate. 
In this example, the extension field is used to 
hold the hash digest of the CA's identity 
certificate, the capabilities to enable the 
requested cryptography strength, and the 
expiration date for the token. 


It is noted that the token may be implemented using other 
types of data structures instead of the X.509 certificate. 
Essentially any type of signed data structure that identifies 
the issuer (i.e., the cryptographic product provider) and 
allows the inclusion of additional data may be used. There 
must be a means to uniquely identify the token in the data 
such as a serial number to enable the issuing authority to 
subsequently identify the token for revocation purposes. 

At step 142 in FIG. 5, the cryptographic product provider 
22 digitally signs the token 42 using its private signing key 
K^p . The cryptographic product provider 22 then returns 
the signed token 42 to the certifying authority 24 (step 144). 
Again, this step may involve encryption to securely pass the 
token back to the certifying authority 24. Key information 
included in the token 42 are the hash digest of the CA 
identity certificate, the capabilities to enable the cryptogra- 
phy strength being granted to the certifying authority, the 
expiration date of the token, the token's serial number, and 
the cryptographic product provider's ID. 

At step 146 in FIG. 5, the certifying authority 24 verifies 
the product provider's signature using the provider's public 
signing key . The certifying authority then stores the 

token 42 in a local and secure manner for later issuance to 
authorized users (step 148). 

Phase III: Issuance 

FIG. 6 shows steps in a method for issuing capabilities for 
enabling higher strength cryptography from the certifying 
authority to a specific user or client computer 26. This 
method involves issuing a second certificate to the user that 
is signed by the certifying authority. The second certificate 
contains the token/first certificate issued by the crypto- 
graphic product provider 22. Most of the steps are imple- 
mented in software executing on a server at the certifying 
authority 24 and software executing at the client 26. 

At step 160 in FIG. 6, the client 26 generates and sends 
a request 44 for stronger cryptography to the certifying 
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authority 24. The request 44 contains the client's public key 
K u ^ r b and the strength of cryptography being sought (e.g., 
128-bu). The request 44 is transmitted over a network, such 
as a corporate LAN (local area network). If the network is 
not secure, the client may encrypt and sign the request. 

The certifying authority 24 receives the request (step 162 
in FIG. 6) and authenticates the client 26 as a legitimate 
machine (step 164). The certifying authority examines the 
request against its policy on issuing certificates for higher 
strength cryptography (step 166). For instance, the certifying 
authority 24 might determine whether the client resides 
within the United States or can properly use the extra 
strength cryptography in a foreign location. The CA24 may 
also want to know the purpose for which the extra strength 
cryptography is to be used. The certifying authority 24 also 
determines whether it has authority to permit use of the 
requested strength. That is, the certifying authority 24 
should first have a valid, non -expired token from the product 
provider before it can issue strength upgrades to the client 
26. The policy can be made as strict or as lenient as a 
company desires, so long as it complies with the U.S. and 
other international laws regarding exportation of crypto- 
graphic materials. 

If the client is permitted to upgrade the cryptography 
strength, the certifying authority 24 creates a certificate (step 
168 in FIG. 6). The certificate is preferably an X.509 
certificate with the token embedded in the extension field. 
Table 2 shows the structure of the certificate 46 when 
implemented as an X.509 certificate. 


TABLE 2 


Certificate Structure 

Field 

Function 

Version 

Identifies the certificate format. 

Serial Number 

Unique identifier assigned to certificate. 

Algorithm ID 

Identifies the type of algorithm used to sign the 


certificate, together with any parameters. 

Issuer 

Name of certifying authority. 

Period of Validity 

Specifies a pair of dates, between which the 


certificate is valid. 

Subject 

Name of client. 

Subject's Public Key 

Specifics a cryptography algorithm, 


parameters used in the algorithm, and the 


client's public key. 

Signature 

Certifying authority's signature. 

Extension 

Holds the token issued and signed by the 


cryptographic product provider. 


At step 170 in FIG. 6, the certifying authority 24 digitally 
signs the certificate 46 using its private signing key .. 
The certifying authority 24 then returns the signed certificate 
46, with embedded token 42, to the client 24 (step 172). Key 
information included in the certificate 46 are the certificate 
ID or serial number, the certifying authority's ID, and the 
token 42. 

At step 174 in FIG. 6, the client 26 verifies the CA's 
signature using the CA*s public signing key K t=AP _^. The 
client 26 stores the certificate 46 and the token 42 in a local 
and secure memory for later use (step 176). 

It is noted that the tokens may be passed through many 
intermediate certifying authorities before being issued to the 
ultimate user. In a corporate environment, for instance, the 
product provider may grant a token to a primary corporate 
server (e.g., a server located in the main U.S. headquarters) 
that acts as a root for an authorization chain. From this root 
server, the administrator issues the token to various nodes, 
such as different subsidiaries of the corporation. The admin- 
istrator might issue a certificate to a subsidiary in the U.S. 
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20 


25 


40 


45 


60 


65 


and other certificates to subsidiaries overseas. From this 
level, the certificates with embedded tokens may be passed 
to individual divisions within the subsidiaries, and so on. 
Finally, the certificates are issued to individual clients for 
use. The advantage to employing certificates for both the 
tokens themselves and the mechanisms for carrying the 
tokens is that the chain of authority may be easily traced 
back through each intermediate certifying authority to the 
root certifying authority and ultimately the product provider. 
Phase IV: Use 

FIG. 7 shows steps in a method for using the capabilities 
to enable higher strength cryptography at the client 26. This 
method involves passing the certificate and token into the 
cryptographic product 28 to expose the higher strength 
cryptography functionality. The steps in this method are 
implemented in software executing at the client 26. 

At step 180 in FIG. 7, a user application 32 running at the 
client 26 initiates a call via the API 34 requesting stronger 
cryptography. As an example, the user application 32 might 
be a personal finance application program that requests a 
128-bit cipher 38. The user application 32 retrieves the 
certificate 46 and token 42 from memory and passes them in 
as parameters in the function call (step 182). 

The cryptographic services 30 of the product 28 use the 
certificate 46 and token 42 to make several verifications. 
First, the cryptographic service 30 traces an authentication 
chain contained in the certificate to the root certifying 
authority (step 184). In this case, the service 30 establishes 
that the certificate 46 was issued is and signed by the 
certifying authority 24, which is recognized by the service 
30 as a valid and authentic authority. In a second verification 
process, the cryptographic service 30 examines the token to 
verify whether it originated from the product provider 22 
and has not be subsequently altered (step 186). 

In a third verification process, the cryptographic service 
30 verifies the link between the authentication chain to the 
certifying authority and the authentication chain to the 
product provider (step 188). The cryptographic service 30 
evaluates the hash digest contained in the token 42 to 
determine whether the digest is for one of the certifying 
authorities in the certificate's authorization chain. In the 
example of one certitying authority, the cryptographic ser- 
vice provider 30 computes a hash digest of the CA's identity 
certificate using the same hashing function H and compares 
the result with the hash digest contained in the token 42. If 
they match, a link is positively established. 

At step 190, the cryptographic service 30 checks the 
expiration dates of the token 42 and certificate 46. The 
certificate and token are approved if they have not yet been 
expired. 

At step 192 in FIG, 7, the cryptographic service 30 
examines the ID of the token 42 against a certificate revo- 
cation list (CRL) to determine whether the token has been 
revoked. The product provider occasionally publishes the 
CRL with all token IDs that have been revoked (e.g., once 
a day or once a week). The token is considered valid if it is 
within its validity period and its serial number has not been 
published on the currently valid CRL. 

If any one of the checks in steps 184 to 192 return false, 
the cryptographic service 30 denies the request for higher 
strength cryptography and continues to expose only the 
export grade functionality (step 194). Conversely, if all 
checks in steps 184 to 192 return true, the cryptographic 
service 30 grants the request for higher strength cryptogra- 
phy and exposes the stronger grade functionality (step 196). 
In this example, the cryptographic service 30 exposes the 
128-bit cipher 38. 
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Although the invention has been described in language including the token with the authorization certificate; 

specific to structural features and/or methodological steps, it transferring the authorization certificate and the token 

is to be understood that the invention defined in the from the certifying authority to the client; 

appended claims is not necessarily limited to the specific (C) performing a use phase at the client, comprising the 

features or steps described. Rather, the specific features and 5 following steps: 

steps are disclosed as exemplary forms of implementing the verifying that the authorization certificate originated 

claimed invention. from the certifying authority; 

What is claimed is: verifying that the token originated from the product 

1. A method for enabling multiple cryptography strengths provider; 

in a cryptographic product supplied by a product provider, verifying that the token contains the hash digest of the 

comprising the following steps: certifying authority's identity certificate; and 

exposing a first cryptography strength in the crypto- if the verifying steps in step (C) return true, utilizing the 

graphic product; capabilities contained in the token to expose the high 

obtaining a certificate from a certifying authority to use a strength cryptography in the cryptographic product, 

second cryptography strength in the cryptographic 6- A method as recited in claim 5, wherein the step (C) 

product, the certificate containing a token from the 15 further comprises the step of determining whether at least 

product provider with capabilities to enable the second one of the token or the authorization certificate has been 

cryptography strength and information for verifying revoked by the product provider. 

that the token was granted to the certifying authority; 7. A method as recited in claim 5, wherein the step (C) 

and further comprises the step of determining whether at least 

exposing the second cryptography strength in the cryp- 20 one of the token or the authorization certificate has expired, 

tographic product with assistance from the capabilities 8. Computer-readable media distributed at the product 

included in the certificate. provider, the certifying authority, and the client comprising 

2. A method as recited in claim 1 further comprising the computer-executable instructions for performing the steps 
following steps: verifying that the certificate originated from recited in claim 5. 

the certifying authority; verifying that the capabilities origi- 25 9 A mem od for upgrading a cryptographic product 

nated from the product provider; and verifying that the installed on a client computer from using low strength 

capabilities were granted to the certifying authority. cryptography to using high strength cryptography, compris- 

3. A method as recited in claim 1 further comprising the . tfae followmg steps: 

step of determining whether the certificate has been revoked. .... . j/, ^ c * u 

4. A method as recited in claim 1, further comprising the 30 ° btaull ?8 a sl S ned l ° ken & om a P rov,der of tl ! e ,? f ry P t °- 
step of determining whether the certificate has expired. graphic product, he token containing capabilities to 

5 A method for enabling high strength cryptography in a ex P ose he , hl 8 h *™* th C T°f^ P V ^,u I t ? 

cryptographic product supplied by a product provider, the of a P artlcular < xttl£ V B * authont y ,0 whlch the token 15 

cryptographic product being installed on a client and ini- * ssac ' . . . 

tiaUy exposing a low strength cryptography without expos- 35 S eneratia g a certificate containing the identity of the 

ing the high strength cryptography, the method comprising certifyng authority; 

the following steps: embedding the signed token within the certificate; and 

(A) performing a registration phase between a certifying transferring the certificate with embedded token to the 
authority and the product provider, comprising the client computer. 

following steps: 40 ^ method as recited in claim 9, further comprising the 

submitting a request from the certifying authority to the step of utilizing the capabilities contained in the signed 

product provider, the request containing an identity token to expose the higher strength cryptography in the 

certificate of the certifying authority and a desired cryptographic product. 

cryptography strength; 11. A method as recited in claim 9, further comprising the 

verifying, at the product provider, an authenticity of the 45 following steps: 

certifying authority; verifying that the certificate originated from the certifying 

computing, at the product provider, a hash digest of the authority; 

identity certificate; verifying that the token originated from the product 

creating, at the product provider, a token containing the provider; and 

hash digest of the identity certificate and capabilities 50 verifying that the signed token contains the identity of the 

to enable the desired cryptography strength; certifying authority, 

transferring the token from the product provider to the 12. A method as recited in claim 9, further comprising the 

certifying authority; step of determining at least one of whether the signed token 

(B) performing an issuance phase between the certifying has been revoked by the product provider or whether the 
authority and the client, comprising the following 55 certificate has been revoked by the certifying authority, 
steps: 13. A method as recited in claim 9, further comprising the 
submitting a request from the client to the certifying step of determining whether at least one of the signed token 

authority, the request containing an identity of the or certificate has expired. 

client and a particular cryptography strength; 14. A computer programmed to perform the steps of the 

verifying, at the certifying authority, an authenticity of 60 method recited in claim 9. 

the client; 15. A computer-readable media having computer- 
evaluating, at the certifying authority, whether the executable instructions for performing the steps of the 

client may be granted the particular cryptography method recited in claim 9, 

strength; 16. In a cryptographic product that is capable of employ- 
creating, at the certifying authority, an authorization 65 ing varying strength cryptography including at least low and 
certificate that contains an identity of the certifying high strength cryptography, a method for exposing the high 
authority; strength cryptography comprising the following steps: 
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initially exposing the low strength cryptography without 
exposing the high strength cryptography; 

receiving a certificate from a certifying authority, the 
certificate carrying a token granted by a provider of the 
cryptographic product, the token containing capabili- 
ties to expose the higher strength cryptography in the 
cryptographic product and an identity of the certifying 
authority; 

verifying that the certificate originated from the certifying 
authority; 

verifying that the token originated from the product 
provider; 

verifying that the token contains the identity of the 
certifying authority; and 

if the verifying steps return true, utilizing the capabilities 
contained in the token to expose the high strength 
cryptography in the cryptographic product. 

17. A method as recited in claim 16, further comprising 
the step of determining whether at least one of the token or 
certificate has been revoked by the product provider. 

18. A method as recited in claim 16, further comprising 
the step of determining whether at least one of the token or 
certificate has expired. 

19. A computer programmed to perform the steps of the 
method recited in claim 16. 

20. A computer-readable media having computer- 
executable instructions for performing the steps of the 
method recited in claim 16. 

21. A system comprising: 
a client; 

at least one cryptographic-based product installed on the 
client, the product being capable of using multiple 
strength cryptography including at least low and. high 
strength cryptography, the product initially exposing 
the low strength cryptography without exposing the 
high strength cryptography; 

a server located at a certifying authority separate from the 
client; 

the client being configured to submit a request to the 
server for authorization to expose the high strength 
cryptography; 

the server being configured to generate an authorization 
certificate in response to the request, the authorization 
certificate containing an identity of the certifying 
authority and a token from a provider of the 
cryptographic-based product, the token containing 
capabilities to expose the higher strength cryptography 
in the cryptographic product and an encoded identity of 
the certifying authority, the server passing the authori- 
zation certificate and the token to the client; and 

the cryptographic-based product being configured to 
verify an authenticity of the authorization certificate 
and an authenticity of the token, and to expose the high 
strength cryptography using the capabilities contained 
in the token. 

22. A system as recited in claim 21, wherein the token is 
embodied as a digital certificate that is attached to the 
authorization certificate. 

23. A system as recited in claim 21, wherein the 
cryptographic-based product uses the encoded identity of the 
certifying authority in the token to verify that the token was 
issued to the certifying authority. 

24. A system as recited in claim 21, wherein the 
cryptographic-based product determines, prior to exposing 
the high strength cryptography, whether one of the authori- 
zation certificate or the token has been revoked. 


)8,266 Bl 

14 

25. A system as recited in claim 21, wherein the 
cryptographic -based product determines, prior to exposing 
the high strength cryptography, whether one 19 of the 
authorization certificate or the token has expired. 
5 26. A data structure embodied on a computer-readable 
medium, comprising: 

an issuer field to hold an identity of a certifying authority 
that issues a digital certificate for enabling a crypto- 
graphic product to expose one or more strengths of 
10 cryptography; 

a subject field to hold an identity of a client to which the 

digital certificate is issued; and 
an extension field to hold a digital token issued by a 
provider of the cryptographic product, the token con- 
15 taining capabilities to expose the one or more strengths 
of cryptography in the cryptographic product and an 
encoded identity of the certifying authority. 
27. A data structure as recited in claim 26, wherein the 
token is embodied as a second digital certificate. 
20 28. A data structure as recited in claim 26, further com- 
prising a period of validity field to hold information indi- 
cating when the certificate is valid. 

29. In a cryptographic product that is capable of employ- 
ing varying strength cryptography including at least low and 

25 high strength cryptography, a method for exposing the high 
strength cryptography comprising the following steps: 
receiving a certificate from a certifying authority, the 
certificate carrying a token granted by a provider of the 
3Q cryptographic product, the token containing capabili- 
ties to expose the higher strength cryptography in the 
cryptographic product and an identity of the certifying 
authority; and 

utilizing the capabilities contained in the token to expose 
35 the high strength cryptography in the cryptographic 
product. 

30. A method as recited in claim 29, further comprising 
determining whether at least one of the token or the certifi- 
cate has been revoked by the product provider. 

40 31. A method as recited in claim 29, further comprising 
determining whether at least one of the token or the certifi- 
cate has expired. 

32. A computer programmed to perform the steps of the 
method recited in claim 29. 
45 33. A computer-readable media having computer- 
executable instructions for performing the steps of the 
method recited in claim 29. 

34. A system comprising: 

a computer; 

50 at least one cryptographic-based product installed on the 
computer, the product being capable of using multiple 
strength cryptography including at least low and high 
strength cryptography, the product initially exposing 
the low strength cryptography without exposing the 

55 high strength cryptography; 

the computer being configured to submit a request to a 
server for an authorization certificate to expose the high 
strength cryptography, the authorization certificate con- 
taining a token from a provider of the cryptographic- 

60 based product, the token containing capabilities to 
expose the higher strength cryptography in the crypto- 
graphic product; and 
the cryptographic-based product being configured to 
verify an authenticity of the authorization certificate 

65 and an authenticity of the token and to expose the high 
strength cryptography using the capabilities contained 
in the token. 
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35. A system as recited in claim 34, wherein the token is 
embodied as a digital certificate that is attached to the 
authorization certificate. 

36. A system as recited in claim 34, wherein the token also 
contains an encoded identity of the certifying authority and 5 
the cryptographic-based product uses the encoded identity of 
the certifng authority in the token to verify that the token 
was issued to the certifying authority. 

37. A system as recited in claim 34, wherein the 
cryptographic-based product determines, prior to exposing 10 
the high strength cryptography, whether one of the authori- 
zation certificate or the token has been revoked. 

38. A system as recited in claim 34, wherein the 
cryptographic-based product determines, prior to exposing 
the high strength cryptography, whether one of the authori- is 
zation certificate or the token has expired. 

39. A system comprising: 
a computer; and 

a server installed on the computer to generate an autho- 
rization certificate in response to a request from a client 20 
with a cryptographic -based product, the authorization 
certificate containing an identity of a certifying author- 
ity and a token from a provider of the cryptographic- 
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based product, the token containing capabilities to 
expose higher strength cryptography in the crypto- 
graphic product and an encoded identity of the certi- 
fying authority, the server passing the authorization 
certificate and the token to the client. 
40. A system for upgrading a cryptographic product 
installed on a client computer from using low strength 
cryptography to using high strength cryptography, compris- 
ing: 

means for obtaining a signed token from a provider of the 
cryptographic product, the token containing capabili- 
ties to expose the high strength cryptography and an 
identity of a particular certifying authority to which the 
token is issued; 

means for generating a certificate containing the identity 
of the certifying authority; 

means for embedding the signed token within the certifi- 
cate; and 

means for transferring the certificate with embedded 
token to the client computer. 
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